[7060][ADD] stock_acceptance_number, stock_acceptance_label: print acceptance labels from transfers - #13
[7060][ADD] stock_acceptance_number, stock_acceptance_label: print acceptance labels from transfers#13kanda999 wants to merge 21 commits into
Conversation
Add an acceptance label printed from transfers (3 per A4 portrait sheet), so that the incoming goods can be tagged with their acceptance number and the result of the acceptance test can be marked by hand on the label.
The date to be printed as the arrival date differs between operations, so the effective date of the transfer cannot always be used. Let the field be selected in the inventory settings, among the date and datetime fields of the transfer and of its lines, and keep the effective date of the transfer as the default.
The goods are accepted per lot, so the lot number and the expiration date of that lot belong on the label as well. They stay blank while the lots of the line are unknown, and a line received in several lots prints them all. The barcode becomes a row of the table like every other value, instead of a picture below it, so that the whole label reads as a single form. The status area is what differs the most between operations, so it moves to the inventory settings as editable HTML. The built-in area is printed as long as the setting is left empty, which keeps it translated. Depends on product_expiry, which is where the expiration date of a lot comes from.
The layout of the label was an asset of web.report_assets_common, which is fetched over HTTP by wkhtmltopdf and shared by every report of the database. A base URL that cannot be reached therefore produced a label without page breaks nor fixed bands, silently, and the rules were loaded by reports that have no use for them. Move the rules into a style element of the report template, so that the layout travels with the markup it applies to and the module needs no asset bundle. The rendered PDF is unchanged.
|
To use Codex here, create a Codex account and connect to github. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 919233bb26
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| class StockMove(models.Model): | ||
| _inherit = "stock.move" | ||
|
|
||
| acceptance_number = fields.Char(copy=False) |
There was a problem hiding this comment.
Prevent differently numbered moves from merging
When a draft transfer contains otherwise merge-compatible moves with different acceptance numbers, the normal stock.move confirmation merge does not consider this newly added field, so the moves can collapse into one line and one acceptance number is discarded. Include acceptance_number among the distinct fields used when merging moves so each numbered line still produces its intended label.
Useful? React with 👍 / 👎.
| self.env["ir.config_parameter"].sudo().set_param( | ||
| STATUS_HTML_PARAM, False if is_html_empty(status_html) else status_html |
There was a problem hiding this comment.
Keep the built-in status area language-dependent
When the status parameter is initially unset, get_values() fills this transient field with the built-in area translated for the settings user's language, and saving Inventory settings—even without editing this field—persists that rendered HTML here. Subsequent reports then treat it as custom content and print that one language for every user instead of translating the built-in area for the printing user; leave the parameter unset when the submitted value is the built-in default.
Useful? React with 👍 / 👎.
This comment was marked as off-topic.
This comment was marked as off-topic.
nobuQuartile
left a comment
There was a problem hiding this comment.
Functional review: LGTM
|
@AungKoKoLin1997 |
| @api.onchange("company_id") | ||
| def _onchange_company_id_acceptance_label(self): |
There was a problem hiding this comment.
As we talked, please remove it if it is not necessary. You could consider default attribute if you want the default value.
|
Pushed Review comments
Tests
15 tests pass locally (
|
AungKoKoLin1997
left a comment
There was a problem hiding this comment.
Code Review: LGTM
Co-authored-by: Aung Ko Ko Lin (Quartile) <45355704+AungKoKoLin1997@users.noreply.github.com>
|
@kanda999 |
|
@kanda999, could you review this PR? |
The acceptance number was a plain field of the transfer line, so a line received in several lots could only carry one number, and the lots kept none of their own. The detailed operations now hold the number, the transfer line summarizes the numbers of its operations, and each lot keeps the numbers it was received under. A line of a product without tracking is still numbered on the line itself, which is carried over to its first detailed operation; for a tracked product the field is read-only on the line and is entered per lot instead. The numbers of the lot are computed from its operations rather than appended to on receipt, so that a number corrected, or a receipt cancelled after the fact, drops out instead of staying on the lot for good. Transfers can also be searched by acceptance number.
…alog The acceptance number was only added to the detailed operations list of the Operations tab. The Move Detail dialog, opened from a transfer line, renders its operations through another list view, so the field was missing exactly where a tracked line is numbered per lot. Both list views now carry it, anchored after the lot name rather than the lot reference: only one of the two lot columns is shown at a time, and anchoring on the last of them keeps the number next to the lot in either case. The two move line views moved to their own file, as they inherit views of stock.move.line rather than of stock.picking.
The acceptance number is given when goods are received, so it is of no use on a delivery, an internal transfer or a manufacturing operation. The column is now hidden unless the operation type of the transfer is a receipt, in each of the three lists that show it: the lines of the transfer, the detailed operations opened from it, and the detailed operations of a single line in the Move Detail dialog. Each one reads the operation type the way its own neighbouring columns do, from the parent record or from the context. The transfer list and the search bar are left alone: they span operation types, so there is nothing to gate them on.
A label carries one acceptance number and one lot, but it was printed per transfer line. A line received in several lots had to squeeze them into a single label, listing the lot numbers and the expiration dates as comma separated strings that the reader had to pair up by position. The label is now printed per detailed operation, which is what holds the acceptance number and the lot. A line received in three lots prints three labels, each with its own number, lot and expiration date, and the lot and date rows became plain fields. The helpers that read the label follow the operation: the arrival date still resolves the configured field through the transfer or its line, and the lot helpers that joined several lots are gone, having nothing left to join. The operations are created when the transfer is confirmed, so a transfer still in draft now prints nothing where it used to print its lines.
Limit the operations the acceptance numbers of a lot are read from to those of receipts. The operation type is taken from the transfer line, whose type is stored, rather than from the operation, whose type is only known once it is attached to a transfer.
Flatten both _get_acceptance_numbers into an ordered de-duplication, drop the status area wrapper in favour of calling the company from the label, and seed the first operation through _prepare_move_line_vals rather than overriding create. The create override ran for every stock.move.line in the database and browsed its move one record at a time, to cover paths that cannot carry an acceptance number anyway. _prepare_move_line_vals covers the one that matters, the operations built on confirmation. A hand-added operation no longer inherits the number of its move, which is the only case lost.
|
I'd suggest splitting this module into two:
|
…n module The acceptance number is useful on its own: it records what the goods were received under, is kept on the lot, and is searched from the transfer list. None of that needs a label, and the label was dragging product_expiry into a database that only wanted the number. stock_acceptance_number holds the number on the detailed operations, its summary on the transfer line and the transfer, the numbers kept on the lot, and the three views that show them. It depends on stock alone. stock_acceptance_label keeps the report, the arrival date and status area settings, and the two helpers that read a lot's expiration date and the configured arrival date. It depends on stock_acceptance_number and, for the expiration date, product_expiry. The lot views are renamed to the name of the views they inherit, per the view rule in AGENTS.md.
…icked The components of a manufacturing order are picked from the quants, not from the lots: the dialog lists a location, a lot and the quantity on hand, and it is opened by quant_id rather than by lot_id. The quant now carries the acceptance number of its lot, shown next to the lot in the list the dialog opens and offered in its filter. Both pickers are covered, as the full quant list inherits the simple one. Toshikimi Shigenobu is credited on both modules.
2160a7b to
4366587
Compare
e8f741a to
7c454b1
Compare
…pendencies The description of the label named the module its number comes from, which belongs with the dependency itself; the manifest says why each one is there instead. The quant says why it carries the number of its lot, which is not obvious from a related field: the components of a manufacturing order are picked from the quants, not from the lots.
7c454b1 to
4d9c4ef
Compare
| # The components of a manufacturing order are picked from the quants | ||
| # rather than from the lots, so the number of the lot has to be read | ||
| # and searched here as well. |
There was a problem hiding this comment.
How about add like that in the readme?
When you select a lot-tracked component in the MO, you can search for it by acceptance number in the Quant view when adding a new line in Detailed Operations.
| # The components of a manufacturing order are picked from the quants | |
| # rather than from the lots, so the number of the lot has to be read | |
| # and searched here as well. |

QT7060
Adds an acceptance label that is printed from transfers, three labels per A4 portrait sheet (one per horizontal band).
product_expiry, which the module now depends on.□ 検査中 / ↓ / □ 適合 or □ 不合格) so that it only has to be adjusted; emptying it restores the built-in area, which follows the language of the printing user.Verified on
2rbkk1: 13 tests pass, and the rendered PDF fits eight rows in each 98mm band in both English and Japanese.